Client-side scout and companion in a real-time bidding advertisement system

ABSTRACT

A client-side component in a real-time bidding (RTB) system for video advertisements configures the client device to, in response to a request for a video advertisement sent by the client device to the real-time bidding system, receive a first set of information associated with the video advertisement, parse the received first set of information to obtain the video advertisement and associated pixel firing information, provide the video advertisement to a video player on the client device, and fire a first pixel upon occurrence of a first predefined event associated with the video advertisement.

CROSS REFERENCE TO RELATED APPLICATION

This patent document claims the benefit of priority from U.S.provisional application No. 61/900,902 entitled “CLIENT-SIDE SCOUT ANDCOMPANION IN A REAL-TIME BIDDING ADVERTISEMENT SYSTEM” filed on Nov. 6,2013, which is incorporated by reference herein in its entirety.

BACKGROUND

Many companies seek to attract customers by promoting their products orservices as widely as possible. Online video advertising is a form ofpromotion that uses the Internet and World Wide Web for delivering videoadvertisements to attract customers. Online advertising is oftenfacilitated through companies called online advertising networks thatconnect advertisers to web sites that want to sell advertising space fordisplaying advertisements. Such an advertising network aggregatesadvertisement space supply from various websites (including on-linecontent publishers) and matches the aggregated advertisement spacesupply with advertiser demand. Advertisement exchanges are technologyplatforms used by online advertising networks for buying and sellingonline advertisement impressions. Advertisement exchanges can be usefulto both buyers (advertisers and agencies) and sellers (onlinepublishers) because of the efficiencies they provide. Advertisementexchanges are, however, often limited by the types of advertisementsthey can buy and sell, their inventory size, and abilities to targetspecific viewers (e.g., potential customers).

The growing number of users accessing the Internet using video-playbackcapable wireless devices such as smartphones and tablet devices createsa demand for improvements to online video advertising.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified block diagram of the BRX RTB system that shows anexemplary transaction procedure.

FIG. 2 illustrates a set of operations that can be carried out at aclient device in a real-time bidding (RTB) system for videoadvertisements in accordance with an exemplary embodiment.

FIG. 3 illustrates a set of operations that can be carried out at aclient device in a real-time bidding (RTB) system for videoadvertisements configured to conduct a server-side RTB auction inaccordance with an exemplary embodiment.

FIG. 4 illustrates a set of operations that can be carried out at aclient device in a real-time bidding (RTB) system for videoadvertisements configured to conduct a client-side RTB auction inaccordance with an exemplary embodiment.

FIG. 5 illustrates a set of operations that can be carried out at aclient device in a real-time bidding (RTB) system for videoadvertisements using a Companion client-side component in accordancewith an exemplary embodiment.

FIG. 6 illustrates a simplified diagram of a real-time bidding systemthat includes a plurality of client devices, third-party services,real-time bidding engine, and third-party partners in accordance with anexemplary embodiment.

FIG. 7 illustrates a block diagram of a device within which variousdisclosed embodiments may be implemented.

FIG. 8 illustrates an online video advertisement system that can be usedto accommodate the disclosed embodiments.

DETAILED DESCRIPTION

The disclosed embodiments facilitate RTB transactions, improve trackingand measurement of impressions, and provide additional capabilities andfunctionalities for a real-time bidding system for video advertisementsusing a client-side component that is referred to hereinafter as theScout. The disclosed embodiments also relate to another client-sidecomponent that facilitates real-time bidding operations, and providesadditional capabilities and functionalities, for a secondary/companionadvertisement; the second client-side component is referred tohereinafter as the Companion or the Companion Scout.

For the purposes of illustration, the present application sometimesrefers to existing industry standards and specifications to provideconcrete examples of how the disclosed techniques may be used in an RTBsystem. However, it is understood that the disclosed embodiments can beused in conjunction with other RTB systems and/or standards.

BrightRoll Exchange (BRX) is an implementation of digital videoadvertisement exchange technologies by BrightRoll, Inc. (San Francisco,Calif.) and offers billions of monthly video advertising impressions,reaching millions of users on thousands of web sites and mobileapplications across the different screens, such as web, mobile, tabletand connected TVs. Real-Time Bidding (RTB) allows buyers to bid onadvertisement inventory using their own decisioning technology on animpression-by-impression basis, moving buy-side advertisementdecisioning up the delivery chain to the buyers own platform from thepublisher's advertisement server or exchange. Buyers decide whether tobid on a particular impression, how much they want to pay and whichcreative they want to deliver (unlike non-RTB models that require thebuyer to serve an advertisement when the downstream advertisement serverdetermines the impression meets the buyer's need, and the buyer only hasan opportunity for creative optimization). The auction platformevaluates all the bids, determines the winner and serves the winningcreative.

FIG. 1 is a simplified block diagram of the BRX RTB system that shows anexemplary transaction procedure in a BRX RTB system. The describedprocedure is provided to facilitate the understanding of the work flowof a transaction but is not intended to provide a comprehensivedescription of the BRX RTB system. At 1, the user encounters a video adopportunity on a website or in an application, and a BRX ad request isinitiated. At 2, the BRX issues bid requests to bidders that qualify forthe impression opportunity based on pre-targeting settings. At 3, eachbidder makes an advertisement decision based on the campaigns traffickedwithin their systems and returns a bid response (including, e.g., amaximum bid and the creative details) within the timeout period asdefined in the bid request (e.g., 90 ms). At 4, the BRX conducts asecond-price auction, determines the winning bid, replaces a macro inthe creative URL to reflect the clearing price (e.g., as a ratio of themaximum bid) and serves the associated creative down to the client. At5, the website or application requests the winning creative (therebycommunicating the clearing price to the bidder) and serves the ad to theuser.

The Scout and the Companion of the present application are advertisementserver components that reside at the client side. In some exampleembodiments, the Scout and the Companion are each in the form of a SWF(“Small Web Format”) file that implements the Video Player-Ad InterfaceDefinition (VPAID) specification for digital videos. Such animplementation allows the Scout and the Companion to be loaded andmanaged by a VPAID compliant ad player. SWF is an Adobe Flash fileformat used for multimedia, vector graphics and ActionScript. SWF filescan contain animations or applets. They may also be used for programsusing ActionScript. SWF files allow audio, video and many differentpossible forms of interaction with the end user. Once created, SWF filescan be played by a compliant player, working either as a browser pluginor as a standalone player.

The Video Ad-Serving Template (VAST) is a specification by theInteractive Advertising Bureau (IAB) that provides a common ad responseformat for video players that enables video ads to be served across allcompliant video players. VAST alone, however, only supports relativelysimple in-stream video ad formats. These simple ad formats do notprovide an interactive user experience, and do not allow the advertiserto collect rich interaction details.

Video Player Ad-Serving Interface Definition (VPAID) establishes acommon interface between video players and ad units to allow interactivein-stream ad experiences. VPAID provides a communication protocolbetween video players and ad units, with the intention of allowing asingle executable ad (one that requires software logic to be executed aspart of ad playback) to be displayed in-stream with the publisher'svideo content, in any compliant video player. For instance, VPAID issupposed to enable the executable ad unit to expect and rely upon acommon set of functionality from the video player, and the video playerto expect and rely upon a common set of functionality from theexecutable ad unit. Despite such intentions, VPAID includes manyinconsistencies and fails to provide, by itself, a consistent platform;it further lacks sufficient features for enabling various tracking andmeasurement functionalities, companion ad RTB placements, client-sideRTB transactions, as well as other features and functionalities that maybe needed in current and future RTB products.

In recognition of the above, the Scout can be configured and operated asan interface between the publisher and the advertiser. Such a Scout canbe used for various functions, including addressing one or more theabove shortcomings, and providing additional features and capabilities.To the publisher, the Scout appears as an ad, and to the advertiser, theScout appears as an ad player. Among other functionalities, the Scout inaccordance with the disclosed embodiments, provides, and has controlover, various types of tracking information that may be desired forcollection and analysis. Further, the Scout facilitates on-the-fly addecisioning from the client side. Moreover, the Scout enables theinclusion of overlays, feedback buttons, and allows the user to opt outof viewing at least certain types of advertisements (e.g., AdChoicesfunctionality). Additional features that are enabled in accordance withthe disclosed embodiments, include tracking user engagement (e.g.,whether or not a user has clicked on an interactive ad, what extent ofan ad has been viewed, tracking of user “mouse-over” events, etc.), sitequality measurement (e.g., whether the ad is displayed appropriately,such as whether the child-appropriate ad is being presented, whether thead is in view or is placed within appropriate locations, whether the adis being provided to the correct page, as identified by the URL of thepage, etc.). Such site quality measurements can be collected andprocessed not only to identify the level of quality, but to also improvevarious shortcomings of advertisement provision and placement, ifneeded. For example, feedback may be provided to the users to allow themto take corrective actions. Moreover, the Scout allows gathering of datafrom a large number of vendors and provide the client with specific datacorresponding to specific vendors.

The disclosed embodiments further facilitate client-side RTB, allow theextraction of page URLs, and allow the formation of a control point forad serve positioning (whether or not to play the ad based on theobtained URL). Moreover, it allows the collection of various data, suchas site referral data, and provides a platform for generation of moredetailed and customized billing services based on customer preferencesand needs. Such advantages and benefits are realized through theoperations of the Scout and the Companion that are provided on theclient device.

In various existing video ad systems, there is no flexible control overthe events that actually occur when the ad is displayed. That is, evenwhen a player is asked to perform certain tasks, there is no flexiblemechanism to control and verify that such tasks were actually performedor correctly performed. The Scout in the disclosed system can be used tofill this void because the Scout runs in the ad player on the clientdevice and thus provides a flexible platform that allows any event to bespecified and tracked on an as-needed basis. Such a flexible platformallows collection of data that is not specified as part of a standarddocument (e.g., a VAST document). In addition, new versions (i.e.,iterations) of the Scout/Companion can be readily produced andtransmitted to the publisher player to allow collection of data fornewly defined events or milestones, without the need for the publisherto integrate such changes into a large number (i.e., both in terms ofquantity and type) of publisher players. As such, the Scout/Companionallow changes to collection and monitoring event to occur flexibly andrapidly at a large scale through various iterations to theScout/Companion and/or the associated configuration files.

In some exemplary embodiments, the Scout has a very small footprint(e.g., about 30 Kbytes of code), which allows for efficient transmissionof the Scout to the client device, as well as storage and executionthereon. In some exemplary embodiments, the Scout (and/or the Companion)include instructions that, when executed by the client device, transmitinformation back to the various entities (such as the Brightrollservers, third-party servers, other networked devices, etc.) atparticular instances of time, when particular milestones are reached, orwhen particular events occur.

In an exemplary RTB workflow, where the publisher player makes a requestfor the ad service, and the ad servers respond with the VAST document,the VAST document includes a media file that points to the Scout and topotentially a Companion. The publisher player can load the Scout intoitself using, e.g., the VPAID specification. The Scout operates toprovide various features and functionalities, depending the particularRTB procedure in use. The “classic” case, the server-side RTB case andthe client-side RTB case that are described in the following sectionsprovide three examples of such RTB scenarios where the Scout and/or theCompanion can be advantageously utilized.

Case 1—the classic case: In this case, the Scout is used to serveconsole advertisements that are provided through the BRX system. Thatis, the BRX system, rather than a demand partner, wins the server sideauction for an advertisement. In such cases, the BRX system uses theScout URL to identify the exact creative asset (e.g., ad) that is goingto be played by the publisher player. The classic case can involve avideo (e.g., a Flash Video (FLV), a VPAID unit or a third-party VASTTag. That is, upon its execution, the Scout plays the video, the VPAIDunit, or makes a request to a third-party ad server for a VAST Tag. Insome embodiments, in case of video and VPAID units, the Scout may not beinvolved in “firing pixels” but rather the pixels (e.g., BRX pixels) aregiven to the publisher in, e.g., the BRX VAST response to the adrequest. As such, the Scout will raise the appropriate VPAID events tothe publisher player to indicate those pixels should be fired. It shouldbe noted that the term “firing pixels” refers to triggering an httprequest to a server that is going to log that request to indicate thatsome event has happened. For example, if it is desired to track that anad impression has occurred, an http request with some parameters relatedto the ad can be generated to indicate that the impression has indeedoccurred.

When the classic case includes a request for a third-party VAST Tag, theScout will request a VAST document from a third-party ad server, parsethe resulting VAST document and take at supported video advertisement(e.g., FLV, mp4 or VPAID unit). Such operations are conducted from theclient side. The following pseudo-code provides a simplified set ofoperations that may be conducted by the Scout upon receiving thethird-party VAST document in accordance with an exemplary embodiment.

-   -   1) Take the first MediaFile where type=video/x-flv and        delivery=progressive and duration<=site placement max duration    -   2) If no appropriate creative was found, take the first        MediaFile where type=video/mp4 and duration<=site placement max        duration and Flash player major version>=11.    -   3) If no appropriate creative was found, take the first        MediaFile where type=application/xshockwaveflash and        duration<=site placement max duration.    -   4) If no appropriate creative was found, fail.    -   5) If a creative is found:        -   5A) Check for a related AdParameters element and store the            contents if found.        -   5B) Collect the related tracking events for this creative:            -   Impression, start, creativeView (all of these are fired                on the impression event)            -   firstQuartile, midpoint, thirdQuartile, complete            -   pause, fullscreen, mute, unmute            -   clickthrough    -   6) Scout will then move on to playing the video/vpaid creative    -   6A) If playing VPAID, pass any contents found in AdParameters on        the third-Party VPAID initAd call.    -   6B) Fire the collected tracking pixels at the appropriate event.

In some embodiments, the Scout uses a time-out interval to set a maximumwait time for playback of advertisements. For example, the Scout mayenforce a strict 12-minute timeout between the time that it isinstantiated and the time that the ad must be started. To this end, whenthe Scout loads, it starts a 12-minute timer. If the publisher playerstarts playing the ad (e.g., calls StartAd) within the 12-minuteinterval, the timer is cleared. However, if the timeout period elapseswithout playing the ad, the Scout fires an error pixel reporting theevent, proceeds through its normal stopAd phase, and then raises anAdError event with a message such as: “Timeout reached: 720 seconds.”

Case 2—server-side RTB (or sRTB): In the server side RTB case,third-party partners are also participate in an RTB for a particularimpression. A demand partner is a partner with an ad to be displayed.That is, these partners are provided with information about the pagethat will display the advertisement, and the partners make a decision ifthey want to participate in bidding for the ad. In case of server sideRTB, a demand partner, as opposed to the BRX system wins a server sideauction, and thus the server demand partner is served through the BRXsystem. When one of these partners wins the bid, a flag is used tonotify the Scout that this is an sRTB case. The Scout can then play thecreative, and build and fire all the pixels to the BRX system to trackimpressions, midpoints, quartile points, etc. The Scout is startedsimilar to the VAST Tag run that was described in connection with theclassic case (e.g., type=VAST_TAG with get sr=y, or=<org_id> andpossible gp=<comma separated list of integers>), but will also performadditional work as noted above related to building and firing pixelsthat is not done in the classic VAST Tag case. As such, in the sRTBcase, there is at least one impression pixel, but may be more than onedepending on gp parameter. In some sRTB cases, the Scout will beprovided with additional parameters (e.g., pp (Packaged Pricing) anddcpr (Downstream CPR) parameters). When these additional parameters arepresent, the Scout will attempt to expand PACKAGED_PRICING and DCPRmacros in the provided asset URL, and will include a dcpr dot var whenbuilding BRX impressions.

Case 3—client-side RTB (cRTB): Some site placements are set to receiveBRX ads but also support a client side auction where the Scout offersthe impression to a list of demand source partners. In this case,parameter values can be set to provide the appropriate values or flags.For example, type=r and i=<comma separated list of demand source ids>.The following pseudo-code provides a simplified set of operations thatmay be conducted by the Scout in a cTRB case in accordance with anexemplary embodiment.

-   -   1) During the initAd phase, the Scout makes a request back to        BRX for the console ad and makes a request to each of the demand        sources included.    -   2) Some demand sources respond with a VAST document. The        response contains a bid and is otherwise parsed identically as        described in the classic VAST Tag case.    -   3) An auction may contain one preferred bidder. A preferred        bidder is processed during the auction but is not actually part        of the auction. If a preferred bidder responds to a request with        an ad, that ad is displayed regardless of the console ad bid or        any other bids in the client-side auction.    -   4) After receiving the responses or timing out:        -   4A) If the preferred bidder demand source is not involved or            had no ad, the Scout runs an auction and selects a winner            and a runner up.        -   4B) If the preferred bidder demand source is involved and            has an ad, the Scout selects the preferred bidder as the            winner and no runner up.    -   5) The Scout reports the results of the auction    -   6) If a demand source wins, the Scout builds BRX tracking pixels        for:        -   impression, mid, done, click track    -   7) The Scout builds the Companion string to send to the        Companion Scout    -   8) Scout then moves on to playing the creative (Video/VPAID)        -   8A) If playing VPAID, pass any contents found in            AdParameters on the 3rdParty VPAID initAd call.        -   8B) Fire the collected tracking pixels at the appropriate            events.

In summary, the publisher makes an ad request. The ad servers decide onan ad based on the BRX internal decision making logic and transmit thead to the Scout. The Scout, before playing the ad that was provided toit, makes requests to a number of RTB partners from the client-side sothat the partners which may not have a great deal of technicalintegration know-how but can have access to the technology providedthrough the Scout and the BRX system. The Scout then runs the auction,and plays the ad as described above.

In various implementations, the Scout is uniquely situated to isolatethe publishers and the advertisers from one another and to allowsuccessful RTB operations, tracking and measurements to take place tothe mutual satisfaction of all parties. For instance, the publishers areprotected from bad creatives. The advertisers, on the other hand, areprovided with a standardized (e.g., compliant VPAID and VAST RTB)implementation that allows additional features and functionalities to beprovided as described throughout this document. These features andfunctionalities protect the advertiser and/or the server partners frompublisher limitations. For instance, as opposed to allowing thepublisher to fire pixels for various tracking and measurement purposes,the Scout fires (and/or builds) the pixels as needed. Such anarchitecture provides many benefits since allowing the publishers tofire the pixels can lead to various discrepancies since (1) somepublishers do not uniformly and properly implement standardizedoperations, and (2) some publishers do not have the capability to firethe pixels as needed by the advertisers or demand partners. Thedisclosed embodiments provide further uniformity and consistency foradvertisers since an advertiser's e.g., VPAID unit, which would haveneeded to run on thousands of different implementations of ad players,only needs to run through the Scout, which in turn provides theadvertiser with consistent RTB tracking and measurement operations.

As noted earlier, prior to playback of the video advertisements, theScout may make a request to another ad server, parse a request to an adserver for a VAST document, collect firing pixels and tracking pixelsfor impressions, mids, ends, clicks, etc. Since a VAST document mayrefer to another VAST document, the Scout may also iterate throughseveral VAST documents. The Scout can further perform the followingtasks: provide third-party tracking and measurement, fire off segmentmapping pixels (e.g., pixels that map third-party segments to BRX users)and track the URL of the page that plays the advertisement.

Third-party tracking: The Scout allows the use of third-party servicesfor collecting data about sites that play the advertisements. After itis known which ad is going to play, the third-party trackingmeasurements (e.g., Nielsen, comScore and Telemetry) are initialized.These third-party measurement tools and services are extendable; thatis, new services and tools can be added or existing services can beremoved. For example, a new Scout code can be provided to the client toimplement such changes to third-party services. Third-party trackingservices may include their own libraries (e.g. JavaScript basedlibraries, SWFs, etc.) that can be loaded onto the Scout on theclient-side to track the needed information. For instance, the Scout canembed or execute the third-party JavaScript. Once executed, thethird-party library performs the prescribed actions for collectinginformation that is needed by the third-party service.

Once the data is provided to the third-party service (e.g., after theJavaScript transmits cookie information to Nielsen), the accumulatedthird-party tracking and measurement data can be collected by the BRXsystem (e.g., by providing a campaign ID and site information). In suchthird-party service applications, the Scout provides information (e.g.,fires tags) that populates campaign and advertising information in avariety of different third-party services. It should be noted that ininteractions with some third-party measurement services, the messageexchange is asymmetric. That is, the information is provided to thethird-party service at a higher granularity but the results ofthird-party measurements are often only available at a lower level ofgranularity. Such an asymmetric exchange is often done to protect theprivacy of the users.

Acquisition of page URL: In some instances, it is important to obtainthe URL of the page that includes the advertisement. Such a URL is notalways readily available, since, for example, the ad player is sometimesembedded into a main page via an iFrame or several nested iFrames. TheScout can obtain the main page URL by crawling up the iFrame(s). The URLand identification information (e.g., auction ID obtained from the VASTdocument; also sometime referred to as an “extra”) is sent to the BRXsystem. The collected URLs can be used to provide various additionalfunctionalities, such as to provide a white list (e.g., safe sites),blacklists (prohibited sites), identify bad actors on the Internet,ascertain invalid inventory, etc.

As noted earlier, at various points during the playback of the ad, theScout can fire one or more tracking pixels. These trigger points aredetermined based on occurrences of certain events, or elapsed timeperiods. The elapsed time points (e.g., quartile points) can beascertained with the knowledge of total duration of the ad, which istypically obtained from file metadata. Tracking pixels are URLs (e.g.,BRX or third-party) that are requested to track various ad events. Theseare critical to the BRX system and can be used to expedite billing, aswell as monitoring the effectiveness of various ad campaigns. Whenparsing a VAST document, the Scout collects any tracking pixels providedand fires each of them upon receiving the corresponding event. The Scoutmay find and collect pixels at any number of levels while following VASTwrapper tags. The pixels are often fired in the order they were found.In any given VAST document, the Scout may find any number of pixels foreach event type. All pixels are often fired in the order they werefound. The following table provides a listing of some exemplary eventsand the corresponding pixel firing behaviors for VPAID and Video,respectively.

TABLE 1 Event VPAID Behavior Video Behavior impression Fired uponreceiving Fired upon video progress AdImpression start, creativeViewFired upon receiving the When we try to play the video AdVideoStartevent firstQuartile, midpoint, Fired upon receiving the Fired at 25%,50%, and 75% thirdQuartile corresponding VPAID progress respectivelyAdVideo* event complete Fired upon receiving the Fired upon receivingthe AdiVideoComplete event AdVideoComplete event pause Fired uponreceiving the Fired after pausing playback AdPaused event fullscreenFired after processing a Fired after processing a resizeAd request withresizeAd request with viewMode = ‘fullscreen’ viewMode = ‘fullscreen’mute, unmute Fired after setting the volume Fired after setting thevolume to to 0 or non-0 respectively 0 or non-0 respectivelyClickTracking Fired after receiving and Fired after handling a click onhandling AdClickThrough the ad

In the table 1 above, Click-Tracking refers to tracking a user's actionsof clicking on an advertisement that directs the user to anothercontent, ad or website. It should be noted that, based on the disclosedembodiments, other events and behaviors can be arbitrarily defined andimplemented through the use of the Scout and/or the Companion. Theinformation obtained from the tracking pixels (both from BRX andthird-party VAST tags) are collected and analyzed at the BRX system. Asalso noted earlier, third-party services can also be provided withtracking pixels as needed.

Overlays: The Scout further provides the capability for allowingoverlays to be placed on advertisements. This functionality would not bepresent in the absence of the Scout, if only video or VPAID units werebeing served. However, the Scout allows overlays (e.g., static images,icons, SWFs, etc.) to be positioned at particular locations on the ad(e.g., at specific coordinates). For example, an Adchoices icon can beplaced on the screen to allow the user to opt out of certain types ofadvertisements. As another example, feedback buttons can be placed asoverlays to allow the user to provide feedback.

Companion (sometimes referred to as the “Companion Scout”): TheCompanion is another client-side component that allows dynamic loadingof a companion advertisement (in addition to the primary ad). In oneexample embodiment, the Companion is a SWF. When the Scout is running inthe classic mode that serves a console video or VPAID unit, anycompanion ad that is linked in the console (i.e., within the BRX system)is served alongside the Scout in the VAST response. In the VAST 1 and 2specifications, the companion ads must be included in the initial VASTresponse (or the final VAST response if a VAST wrapper is provided)before the ad is loaded. However, if the Scout is running in the classicmode where it is serving a console third-party VAST Tag, or is runningin cRTB mode or in sRTB mode where a demand partner wins, the ad serversdon't know which, if any, companion ad should be served along side theoriginal ad. In such cases, the companion ad is communicated through asecond VAST request that the Scout makes after it has parsed the firstVAST response.

In order to support third-party VAST Tag functionality, as well as somecRTB and sRTB cases, the publisher is provided with a Companion beforeit is known which (if any) companion ad should be displayed. To thisend, the BRX ad servers respond to the ad request with a VAST documentcontaining the Scout and a Companion (e.g., in an iFrame source tag).The iFrame is loaded as a Companion Scout and is invisible. After theScout has determined which companion ad should be displayed, the Scoutuses a local connection to send the VAST containing the companion ad andthe ID of the companion to be displayed. The Companion Scout on theclient parses the VAST document, builds any appropriate pixels, andembeds the companion ad in its iFrame using, e.g., ExternalInterfacecalls to Javascript embedded in the iFrame.

Communications between the Scout and the Companion are made using alocal connection (e.g., LocalConnection). The following provides anexample of how local connection may be used. The Companion usesExternalInterface to embed content in the iFrame. While the Scout isgenerally loaded first, it is possible that the publisher loads theCompanion Scout first. To handle this, the connection starts with ahandshake phase. The Companion Scout first connects to a unique channel(e.g., “cmd”+companion_xtra). This connection will block until a commandis received. The Companion Scout then attempts to send a ping command toa separate channel (e.g., “ping”+companion_xtra). If the Scout has notyet connected to the ping channel, the command fails, and the CompanionScout will repeat the attempt periodically (e.g., every 250 ms up to 500times). When the Scout finally does connect, or if the Scout hadestablished a connection prior to the loading of the Companion Scout,the ping command is received by the Scout.

Next, the Scout sends a “setstring” command to the command channel(e.g., “cmd”+companion_xtra) and provides the companion string. Thisstring includes the VAST document containing the Companion, the ad ID toidentify the appropriate Companion element (and optionally cRTB winnerinformation). Once the Companion Scout has received the data, it parsesthe VAST document and looks for a Companion to display. If cRTBinformation is sent, the Companion Scout builds the impression and clicktracking pixels. If no Companion is found, none is displayed. If aCompanion is found, the Companion Scout will use ExternalInterface tocall out to the Javascript embedded in its frame. The Javascriptcontains a function for embedding html Companions, iFrame companions,and static Companions. The Companion Shim calls the appropriate embedfunction which will embed the Companion and impression pixels in theiFrame.

The location of companion ad on the page is usually determined by thepublisher. The publisher is given the companion ad and is asked to placein its companion slot. The dimensions of the companion, however, areprovided to the publisher (e.g., a 300×250 pixel area).

FIG. 2 illustrates a set of operations 200 that can be carried out at aclient device in a real-time bidding (RTB) system for videoadvertisements in accordance with an exemplary embodiment. At 202, aclient-side component is received to reside on a tangible storage mediumthe client device. At 204, in response to a request for a videoadvertisement sent by the client device to the real-time bidding system,a first set of information associated with the video advertisement isreceived at the client side component. At 206, the received first set ofinformation is parsed by the client-side component to obtain the videoadvertisement and associated pixel firing information. At 208, the videoadvertisement is provided to a video player on the client device. At210, a first pixel upon occurrence of a first predefined eventassociated with the video advertisement is fired by the client-sidecomponent.

FIG. 3 illustrates a set of operations 300 that can be carried out at aclient device in a real-time bidding (RTB) system for videoadvertisements configured to conduct a server-side RTB auction inaccordance with an exemplary embodiment. At 302, a client-side componentis received to reside on a tangible storage medium at a client device.At 304, in response to a request for a video advertisement sent by theclient device to the real-time bidding system, a first set ofinformation associated with the video advertisement is received, wherethe first set of information including a flag indicates a third-partyentity winner of the auction for the video advertisement. At 306, thereceived first set of information is parsed by the client-side componentto obtain the video advertisement and pixel firing informationassociated with the third-party entity. At 308, additional pixel firinginformation is produced corresponding to the RTB system. At 310, thevideo advertisement is provided to a video player on the client device.At 312, a first pixel is fired by the client-side component uponoccurrence of a first predefined event associated with the videoadvertisement as defined by the RTB system. At 314, a second pixel isfired by the client-side component upon occurrence of a secondpredefined event associated with the video advertisement as defined bythe third-party entity.

FIG. 4 illustrates a set of operations 400 that can be carried out at aclient device in a real-time bidding (RTB) system for videoadvertisements configured to conduct a client-side RTB auction inaccordance with an exemplary embodiment. At 402, a client-side componentis received to reside on a tangible storage medium at a client device.At 404, an offer is provided by the client-side component to one or morethird-party entities to participate in a client-side RTB auction for avideo advertisement of the RTB system. At 406, in response to the offer,a first set of information associated with the video advertisement isreceived, where the first set of information is at least indicative of awinning entity. At 408, the received first set of information is parsedby the client-side component to obtain the video advertisement and pixelfiring information associated with the third-party entity. At 410, thevideo advertisement is provided to a video player on the client device.At 412, a first pixel is fired by the client-side component uponoccurrence of a first predefined event associated with the videoadvertisement.

FIG. 5 illustrates a set of operations 500 that can be carried out at aclient device in a real-time bidding (RTB) system for videoadvertisements using a Companion client-side component in accordancewith an exemplary embodiment. At 502, a client-side companion componentis received to reside on a tangible storage medium at a client device.At 504, in response to a request for a video advertisement sent by theclient device to the real-time bidding system, a first set ofinformation associated with a first version of a companion advertisementis received. At 506, the first version of the companion advertisement isplayed invisibly on a video player on the client device. At 508, asecond set of information comprising a second version of the companionadvertisement is received. At 510, the second version of the companionadvertisement is played on a video player on the client device.

FIG. 6 illustrates a simplified diagram of a real-time bidding systemthat includes a plurality of client devices 602 (only one client device602 is shown). The client device 602 includes a video player 608, aScout 604 component, and a Companion Scout 606 component. The clientdevice 602 further includes communication components 610 that areconfigured to communicate through a network connection with variousentities, including a real-time bidding (RTB) engine 612, one or morethird-party partners 614 and one or more third-party services 616 (e.g.,tracking and measurement service providers such as Neilson, etc.). Thesystem of FIG. 6 enables various operations that are describedthroughout the present application.

Certain aspects of the disclosed embodiments can be implemented as adevice that includes a processor and a memory comprising processorexecutable code. The processor executable code, when executed by theprocessor, configures the device to perform any one of and/or alloperations that are described in the present application. For example,FIG. 7 illustrates a block diagram of a device 700 within which variousdisclosed embodiments may be implemented. The device 700 comprises atleast one processor 707 (e.g., a microprocessor) and/or controller, atleast one memory 702 unit that is in communication with the processor707, and at least one communication unit 707 that enables the exchangeof data and information, directly or indirectly, through thecommunication link 708 with other entities, devices, databases andnetworks. The communication unit 706 may provide wired and/or wirelesscommunication capabilities in accordance with one or more communicationprotocols, and therefore it may comprise the propertransmitter/receiver, antennas, circuitry and ports, as well as theencoding/decoding capabilities that may be necessary for propertransmission and/or reception of data and other information. The device700 also includes a display 710 for displaying the video advertisementand the companion advertisements (if any). The exemplary device 700 ofFIG. 7 may be integrated as part of any of a client device that is shownin FIG. 6.

FIG. 8 depicts a simplified view of an online video advertisementinsertion architecture 800 that can accommodate the disclosedembodiments. An ad viewer's device 802 (e.g., a wireless or a mobiledevice, as discussed above) may be communicatively coupled (e.g., viathe internet and a wired or wireless connection) with an ad server 804.The ad server 804 may communicate bids to show video ads to the device802 to multiple bidders 806 via a plurality of bid server platforms 810.An operator or administrator console 808 may be provided to control theoperation of the ad server 804 and bid servers 810. The ad server 804may also be called front end ad server 804 in the sense that this adserver provides an entry into an online video advertisement system foran ad placement request from a viewer's device. The bid servers 810provide a bidding interface between third party bidding servers and theonline video advertisement service.

The ad server 804 may perform functions such as handling incoming adrequests from multiple ad viewer devices 802, and may respond with an ador a “no ad” placement. The ad server 804 may operate on a time budget,e.g., 50 to 800 msec., within which it responds to an ad request. The adserver 804 may provide ad data to the viewer device 802 using VASTformat. The decision about which advertisement to be sent may be basedon various factors and real time data such as publisher placement,uniform resource locator (URL), a geographic location of the viewerdevice, time of day, demographic segment to which the viewer belongs,and so on.

When the ad server 804 receives a video placement request from theviewer's device 802, the ad server 804 may pass on the request to two ormore bid servers 880. The request may include information about theviewer, the viewer's demographic profile and other rules associated withthe ad placement opportunity that may influence the selection of awinning bid. In some embodiments, the front end ad servers 804, bidservers 810 and the administrator's console 808 may be part of a videoad insertion platform 882 offered by a single vendor, e.g., the BRXplatform offered by Brightroll, Inc.

The bid servers 810 in turn request bids from multiple third partybidders 806. When bids are received from third party bidders 806, or atthe end of a time period (e.g., 90 milliseconds), a decision is madeabout the winning bid. In some embodiments, the winning bid not onlywill have the highest dollar value but also should match the demographicprofile of the viewer. For example, if the viewer is on the West coast,an advertisement for users on East coast may not be allowed to win bideven when the third party bidder bids the highest dollar value. Thewinning bidder is then notified for winning the bid. The winning bidderis provided with information to allow the winning bidder to transmit avideo advertisement to the viewer.

As noted previously, the Scout and/or the Companion components (notshown in FIG. 8) reside at the ad viewer device(s) 802 and communicatewith the Video Ad Insertion Platform 812, as well as third-party serviceproviders (not shown in FIG. 8).

Various aspects of the disclosed technology can be embodied as outlinedin the following clauses.

Clause 1. A client-side component in a real-time bidding (RTB) systemfor video advertisements, the component comprising program code storedon a tangible storage media that when executed by a processor of aclient device, operates the client device to participate in aserver-side RTB auction and to: in response to a request for a videoadvertisement sent by the client device to the real-time bidding system,receive a first set of information associated with the videoadvertisement, the first set of information including a flag indicatinga third-party entity winner of the auction for the video advertisement;parse the received first set of information to obtain the videoadvertisement and pixel firing information associated with thethird-party entity; produce additional pixel firing informationcorresponding to the RTB system; provide the video advertisement to avideo player on the client device; fire a first pixel upon occurrence ofa first predefined event associated with the video advertisement asdefined by the RTB system; and fire a second pixel upon occurrence of asecond predefined event associated with the video advertisement asdefined by the third-party entity.

Clause 2. The client-side component of clause 1, wherein the videoadvertisement is one of a flash video (FLV) or a Video Player Ad-ServingInterface Definition (VPAID) unit.

Clause 3. The client-side component of clause 1, wherein the first setof information is provided through a Video Ad-Serving Template (VAST)document that includes a third-party VAST tag, and the program code whenexecuted by the processor configures the device to obtain the videoadvertisement using the third-party VAST Tag.

Clause 4. The client-side component of clause 1, wherein the programcode when executed by the processor configures the device to furtherprovide an overlay on the video advertisement.

Clause 5. The client-side component of clause 4, wherein the overlayprovides one or more of the following: an icon, a selection menu, or afeedback button.

Clause 6. The client-side component of clause 1, wherein the firstpredefined event is one of: a reception of an advertisement impression,an initiation of playback of the video advertisement, a first quartileplayback of the video advertisement, a midpoint playback of the videoadvertisement, a third quartile playback of the video advertisement, acomplete playback of the video advertisement, a pause in playback of thevideo advertisement, a resizing of the video advertisement, a change inaudio level of the video advertisement, or a user interaction associatedwith the video advertisement.

Clause 7. The client-side component of clause 1, wherein the programcode when executed by the processor further configures the device toobtain a uniform resource locator (URL) corresponding to a web page inwhich the video advertisement is to be played.

Clause 8. The client-side component of clause 1, wherein the programcode when executed by the processor further operates the device toexecute a program associated with a third-party service provider andfire one or more pixels to a destination provided by the third-partyservice provider upon occurrence of a predefined event as defined by thethird-party service provider.

Clause 9. The client-side component of clause 1, wherein the programcode when executed by the processor configures the client side componentto operate as an interface between a video player on the client device,and a provider of the video advertisement.

Clause 10. The client-side component of clause 1, wherein theclient-side component is reconfigurable so that additionalfunctionalities can be added or removed from the client side componentin each new version of the client-side component or each new version ofan associated configuration file.

Clause 11. The client-side component of clause 1 wherein the client-sidecomponent is no larger than about 30 Kbytes.

Clause 12. A client-side component in a real-time bidding (RTB) systemfor video advertisements, the component comprising program code storedon a tangible storage media that when executed by a processor of aclient device, operates the client device to participate in aclient-side RTB auction and to provide an offer by the client-sidecomponent to one or more third-party entities to participate in aclient-side RTB auction for a video advertisement of the RTB system, inresponse to the offer, receive a first set of information associatedwith the video advertisement, the first set of information at leastindicative of a winning entity, parse the received first set ofinformation to obtain the video advertisement and pixel firinginformation associated with the third-party entity, provide the videoadvertisement to a video player on the client device, and fire a firstpixel upon occurrence of a first predefined event associated with thevideo advertisement.

Clause 13. The client-side component of clause 12, wherein the videoadvertisement is one of a flash video (FLV) or a Video Player Ad-ServingInterface Definition (VPAID) unit.

Clause 14. The client-side component of clause 12, wherein the first setof information is provided through a Video Ad-Serving Template (VAST)document that includes a third-party VAST tag, and the program code whenexecuted by the processor configures the device to obtain the videoadvertisement using the third-party VAST Tag.

Clause 15. The client-side component of clause 12, wherein the programcode when executed by the processor configures the device to furtherprovide an overlay on the video advertisement.

Clause 16. The client-side component of clause 15, wherein the overlayprovides one or more of the following: an icon, a selection menu, or afeedback button.

Clause 17. The client-side component of clause 12, wherein the firstpredefined event is one of: a reception of an advertisement impression,an initiation of playback of the video advertisement, a first quartileplayback of the video advertisement, a midpoint playback of the videoadvertisement, a third quartile playback of the video advertisement, acomplete playback of the video advertisement, a pause in playback of thevideo advertisement, a resizing of the video advertisement, a change inaudio level of the video advertisement, or a user interaction associatedwith the video advertisement.

Clause 18. The client-side component of clause 12, wherein the programcode when executed by the processor further configures the device toobtain a uniform resource locator (URL) corresponding to a web page inwhich the video advertisement is to be played.

Clause 19. The client-side component of clause 12, wherein the programcode when executed by the processor further operates the device toexecute a program associated with a third-party service provider andfire one or more pixels to a destination provided by the third-partyservice provider upon occurrence of a predefined event as defined by thethird-party service provider.

Clause 20. The client-side component of clause 12, wherein the programcode when executed by the processor configures the client side componentto operate as an interface between a video player on the client device,and a provider of the video advertisement.

Clause 21. The client-side component of clause 12, wherein theclient-side component is reconfigurable so that additionalfunctionalities can be added or removed from the client side componentin each new version of the client-side component or each new version ofan associated configuration file.

Clause 22. The client-side component of clause 12 wherein theclient-side component is no larger than about 30 Kbytes.

Clause 23. A method for facilitating playback and tracking a videoadvertisement in a real-time bidding (RTB) system configured to conducta server-side RTB auction, the method comprising: receiving aclient-side component to reside on a tangible storage medium at a clientdevice, in response to a request for a video advertisement sent by theclient device to the real-time bidding system, receiving a first set ofinformation associated with the video advertisement, the first set ofinformation including a flag indicating a third-party entity winner ofthe auction for the video advertisement, parsing the received first setof information by the client-side component to obtain the videoadvertisement and pixel firing information associated with thethird-party entity, producing additional pixel firing informationcorresponding to the RTB system, providing the video advertisement to avideo player on the client device, firing by the client-side component afirst pixel upon occurrence of a first predefined event associated withthe video advertisement as defined by the RTB system, and firing by theclient-side component a second pixel upon occurrence of a secondpredefined event associated with the video advertisement as defined bythe third-party entity.

Clause 24. The method of clause 23, further comprising providing anoverlay for display on top the video advertisement.

Clause 25. The method of clause 24, wherein the overlay provides one ormore of the following: an icon, a selection menu, or a feedback button.

Clause 26. The method of clause 23, wherein the first predefined eventis one of: a reception of an advertisement impression, an initiation ofplayback of the video advertisement, a first quartile playback of thevideo advertisement, a midpoint playback of the video advertisement, athird quartile playback of the video advertisement, a complete playbackof the video advertisement, a pause in playback of the videoadvertisement, a resizing of the video advertisement, a change in audiolevel of the video advertisement, or a user interaction associated withthe video advertisement.

Clause 27. The method of clause 23, further comprising obtaining auniform resource locator (URL) corresponding to a web page in which thevideo advertisement is to be played.

Clause 28. The method of clause 23, further comprising: executing aprogram associated with a third-party service provider; and firing oneor more pixels to a destination provided by the third-party serviceprovider upon occurrence of a predefined event as defined by thethird-party service provider.

Clause 29. The method of clause 23, wherein the client side component tooperates as an interface between a video player on the client device,and a provider of the video advertisement.

Clause 30. The method of clause 23, wherein the client-side component isreconfigurable so that additional functionalities can be added orremoved from the client side component in each new version of theclient-side component or each new version of an associated configurationfile.

Clause 31. The method of clause 23, wherein the client-side component isno larger than about 30 Kbytes.

Clause 32. A method for facilitating playback and tracking a videoadvertisement in a real-time bidding (RTB) system configured to conducta client-side RTB auction, the method comprising: receiving aclient-side component to reside on a tangible storage medium at a clientdevice, providing an offer by the client-side component to one or morethird-party entities to participate in a client-side RTB auction for avideo advertisement of the RTB system, in response to the offer,receiving a first set of information associated with the videoadvertisement, the first set of information at least indicative of awinning entity, parsing the received first set of information by theclient-side component to obtain the video advertisement and pixel firinginformation associated with the third-party entity, providing the videoadvertisement to a video player on the client device, and firing by theclient-side component a first pixel upon occurrence of a firstpredefined event associated with the video advertisement.

Clause 33. The method of clause 32, further comprising providing anoverlay for display on top the video advertisement.

Clause 34. The method of clause 33, wherein the overlay provides one ormore of the following: an icon, a selection menu, or a feedback button.

Clause 35. The method of clause 32, wherein the first predefined eventis one of: a reception of an advertisement impression, an initiation ofplayback of the video advertisement, a first quartile playback of thevideo advertisement, a midpoint playback of the video advertisement, athird quartile playback of the video advertisement, a complete playbackof the video advertisement, a pause in playback of the videoadvertisement, a resizing of the video advertisement, a change in audiolevel of the video advertisement, or a user interaction associated withthe video advertisement.

Clause 36. The method of clause 32, further comprising obtaining auniform resource locator (URL) corresponding to a web page in which thevideo advertisement is to be played.

Clause 37. The method of clause 32, further comprising: executing aprogram associated with a third-party service provider; and firing oneor more pixels to a destination provided by the third-party serviceprovider upon occurrence of a predefined event as defined by thethird-party service provider.

Clause 38. The method of clause 32, wherein the client side component tooperates as an interface between a video player on the client device,and a provider of the video advertisement.

Clause 39. The method of clause 32, wherein the client-side component isreconfigurable so that additional functionalities can be added orremoved from the client side component in each new version of theclient-side component or each new version of an associated configurationfile.

Clause 40. The method of clause 32, wherein the client-side component isno larger than about 30 Kbytes.

Clause 41. A computer program product for facilitating playback andtracking a video advertisement in a real-time bidding (RTB) systemconfigured to conduct a server-side RTB auction, the computer programproduct embodied on a non-transitory storage medium at a client deviceof the RTB system, the computer program product comprising: program codefor, in response to a request for a video advertisement sent by theclient device to the real-time bidding system, receiving a first set ofinformation associated with the video advertisement, the first set ofinformation including a flag indicating a third-party entity winner ofthe auction for the video advertisement, program code for parsing thereceived first set of information to obtain the video advertisement andpixel firing information associated with the third-party entity, programcode for producing additional pixel firing information corresponding tothe RTB system, program code for providing the video advertisement to avideo player on the client device, program code for firing a first pixelupon occurrence of a first predefined event associated with the videoadvertisement as defined by the RTB system, and program code for firinga second pixel upon occurrence of a second predefined event associatedwith the video advertisement as defined by the third-party entity.

Clause 42. A computer program product for facilitating playback andtracking a video advertisement in a real-time bidding (RTB) systemconfigured to conduct a client-side RTB auction, the computer programproduct embodied on a non-transitory storage medium at a client deviceof the RTB system, the computer program product comprising: program codefor providing an offer to one or more third-party entities toparticipate in a client-side RTB auction for a video advertisement ofthe RTB system, program code for, in response to the offer, receiving afirst set of information associated with the video advertisement, thefirst set of information further indicative of a winning entity, programcode for parsing the received first set of information to obtain thevideo advertisement and pixel firing information associated with thethird-party entity, program code for providing the video advertisementto a video player on the client device, and program code for firing afirst pixel upon occurrence of a first predefined event associated withthe video advertisement.

Clause 43. A client-side companion component in a real-time bidding(RTB) system for video advertisements, the companion componentcomprising program code stored on a tangible storage media that whenexecuted by a processor of a client device, configures the client deviceto: in response to a request for a video advertisement sent by theclient device to the real-time bidding system, receive a first set ofinformation associated with a first version of a companionadvertisement, provide the first version of the companion advertisementto run invisibly on a video player on the client device, and receive asecond set of information comprising a second version of the companionadvertisement, and provide the second version of the companionadvertisement to run on a video player on the client device.

Clause 44. The client-side companion component of clause 43, wherein thefirst set of information is provided through a Video Ad-Serving Template(VAST) document that includes a third-party VAST tag, and the programcode when executed by the processor configures the device to obtain thesecond set of information using the third-party VAST Tag.

Clause 45. The client-side companion component of clause 42, wherein thesecond set of information is obtained from a third-party entity winnerin one of a server-side RTB auction or a client-side RTB auction.

Clause 46. The client-side component of clause 43, wherein the firstversion of companion advertisement is a dummy version of the companionadvertisement that is used as a substitute for the second version of thecompanion advertisement.

Clause 47. A method for facilitating playback and tracking a videoadvertisement in a real-time bidding (RTB) system, the method includingreceiving a client-side companion component to reside on a tangiblestorage medium at a client device, in response to a request for a videoadvertisement sent by the client device to the real-time bidding system,receiving a first set of information associated with a first version ofa companion advertisement, playing the first version of the companionadvertisement invisibly on a video player on the client device, andreceiving a second set of information comprising a second version of thecompanion advertisement, and playing the second version of the companionadvertisement on a video player on the client device.

Clause 48. A computer program product for facilitating playback andtracking a video advertisement in a real-time bidding (RTB) system, thecomputer program product embodied on a non-transitory storage medium ata client device of the RTB system, the computer program productincluding: program code for, in response to a request for a videoadvertisement sent by the client device to the real-time bidding system,receiving a first set of information associated with a first version ofa companion advertisement, program code for providing the first versionof the companion advertisement to run invisibly on a video player on theclient device, and program code for receiving a second set ofinformation comprising a second version of the companion advertisement,and program code for providing the second version of the companionadvertisement to run on a video player on the client device.

Clause 49. A real-time bidding (RTB) system, including a real-timebidding engine configured to receive a plurality of bids for a videoadvertisement and transmit information comprising bid results, a clientincluding a video player, configured to transmit a request for a videoadvertisement to the real-time bidding engine, a client-side componentcomprising program code stored on a tangible storage media that whenexecuted by a processor of a client device, configures the client deviceto: in response to the request for a video advertisement sent by theclient device, receive a first set of information associated with thevideo advertisement, parse the received first set of information toobtain the video advertisement and associated pixel firing information,provide the video advertisement to the video player on the clientdevice, and fire a first pixel upon occurrence of a first predefinedevent.

Various embodiments described herein are described in the generalcontext of methods or processes, which may be implemented in oneembodiment by a computer program product, embodied in acomputer-readable medium, including computer-executable instructions,such as program code, executed by computers in networked environments. Acomputer-readable medium may include removable and non-removable storagedevices including, but not limited to, Read Only Memory (ROM), RandomAccess Memory (RAM), compact discs (CDs), digital versatile discs (DVD),Blu-ray Discs, etc. Therefore, the computer-readable media described inthe present application include non-transitory storage media. Generally,program modules may include routines, programs, objects, components,data structures, etc. that perform particular tasks or implementparticular abstract data types. Computer-executable instructions,associated data structures, and program modules represent examples ofprogram code for executing steps of the methods disclosed herein. Theparticular sequence of such executable instructions or associated datastructures represents examples of corresponding acts for implementingthe functions described in such steps or processes.

For example, one aspect of the disclosed embodiments relates to acomputer program product that is embodied on a non-transitory computerreadable medium. The computer program product includes program code forcarrying out any one or and/or all of the operations of the disclosedembodiments.

The foregoing description of embodiments has been presented for purposesof illustration and description. The foregoing description is notintended to be exhaustive or to limit embodiments of the presentinvention to the precise form disclosed, and modifications andvariations are possible in light of the above teachings or may beacquired from practice of various embodiments. The embodiments discussedherein were chosen and described in order to explain the principles andthe nature of various embodiments and their practical application toenable one skilled in the art to utilize the present invention invarious embodiments and with various modifications as are suited to theparticular use contemplated. The features of the embodiments describedherein may be combined in all possible combinations of methods,apparatus, modules, systems, and computer program products.

What is claimed is:
 1. A client-side component in a real-time bidding(RTB) system for video advertisements, the client-side componentcomprising program code stored on a non-transitory tangible storagemedia that when executed by a processor of a client device, operates theclient device to: in response to a request for a video advertisementsent by the client device to the RTB system, receive at the client-sidecomponent a first set of information associated with the videoadvertisement; parse at the client-side component the received first setof information to obtain the video advertisement and to build, at theclient-side component, tracking pixels corresponding to differentpredefined events associated with the video advertisement, wherein thepredefined events include at least one of a midpoint playback of thevideo advertisement, a complete playback of the video advertisement, apause in playback of the video advertisement, or a user interactionassociated with the video advertisement; provide the video advertisementfrom the client-side component to a video player on the client device;fire from the client-side component, a first tracking pixel of thetracking pixels upon occurrence of a first predefined event of thepredefined events associated with the video advertisement; and provide,based on the occurrence of the first predefined event, a second set ofinformation from the client-side component to a third-party serviceprovider that populates advertisement campaign information at thethird-party service provider.
 2. The client-side component of claim 1,wherein the video advertisement is one of a flash video (FLV) or a VideoPlayer Ad-Serving Interface Definition (VPAID) unit.
 3. The client-sidecomponent of claim 1, wherein the first set of information is providedthrough a Video Ad-Serving Template (VAST) document that includes athird-party VAST tag, and the program code when executed by theprocessor configures the client device to obtain the video advertisementusing the third-party VAST Tag.
 4. The client-side component of claim 1,wherein the program code when executed by the processor configures theclient device to further provide an overlay on the video advertisement.5. The client-side component of claim 4, wherein the overlay providesone or more of the following: an icon, a selection menu, or a feedbackbutton.
 6. The client-side component of claim 1, wherein the predefinedevents further include at least one of: a reception of an advertisementimpression, an initiation of playback of the video advertisement, afirst quartile playback of the video advertisement, a third quartileplayback of the video advertisement, a resizing of the videoadvertisement, or a change in audio level of the video advertisement. 7.The client-side component of claim 1, wherein the program code whenexecuted by the processor further configures the client device to obtaina uniform resource locator (URL) corresponding to a web page in whichthe video advertisement is to be played.
 8. The client-side component ofclaim 1, wherein the program code when executed by the processor furtherconfigures the client device to: execute a program associated with asecond third-party service provider; and fire one or more pixels to adestination provided by the second third-party service provider uponoccurrence of a second predefined event as defined by the secondthird-party service provider.
 9. The client-side component of claim 1,wherein the program code when executed by the processor configures theclient side component to operate as an interface between a video playeron the client device, and a provider of the video advertisement.
 10. Theclient-side component of claim 1, wherein the client-side component isreconfigurable so that additional functionalities can be added orremoved from the client side component in each new version of theclient-side component or each new version of an associated configurationfile.
 11. The client-side component of claim 1 wherein the client-sidecomponent is no larger than about 30 Kbytes.
 12. The client-sidecomponent of claim 1, wherein the predefined events include one or morepredefined events indicating elapsed time periods of the videoadvertisement.
 13. The client-side component of claim 1, wherein thefirst predefined event occurs after the video advertisement is played onthe video player.
 14. The client-side component of claim 1, wherein theclient-side component runs in an ad player on the client device.
 15. Theclient-side component of claim 1, wherein the client device is a mobilephone.
 16. A method for facilitating playback and tracking a videoadvertisement in a real-time bidding (RTB) system, the methodcomprising: receiving a client-side component to reside on anon-transitory tangible storage medium at a client device; in responseto a request for the video advertisement sent by the client device tothe RTB system, receiving at the client-side component, a first set ofinformation associated with the video advertisement; parsing thereceived first set of information by the client-side component to obtainthe video advertisement and building, at the client-side component,tracking pixels corresponding to respective predefined events associatedwith the video advertisement, wherein the predefined events include atleast one of a midpoint playback of the video advertisement, a completeplayback of the video advertisement, a pause in playback of the videoadvertisement, or a user interaction associated with the videoadvertisement; providing the video advertisement from the client-sidecomponent to a video player on the client device; firing by theclient-side component a first tracking pixel of the tracking pixels uponoccurrence of a first predefined event of the predefined eventsassociated with the video advertisement; and providing, based on theoccurrence of the first predefined event, a second set of informationfrom the client-side component to a third-party service provider thatpopulates advertisement campaign information at the third-party serviceprovider.
 17. The method of claim 16, wherein the first set ofinformation is provided through a Video Ad-Serving Template (VAST)document that includes a third-party VAST tag, and the videoadvertisement is obtained using the third-party VAST Tag.
 18. The methodof claim 16, further comprising providing an overlay for display on topthe video advertisement.
 19. The method of claim 18, wherein the overlayprovides one or more of the following: an icon, a selection menu, or afeedback button.
 20. The method of claim 16, further comprising:executing a program associated with a second third-party serviceprovider; and firing one or more pixels to a destination provided by thethird-party service provider upon occurrence of a second predefinedevent as defined by the second third-party service provider.
 21. Themethod of claim 16, wherein the client side component operates as aninterface between a video player on the client device, and a provider ofthe video advertisement.
 22. The method of claim 16, wherein theclient-side component is reconfigurable so that additionalfunctionalities can be added or removed from the client side componentin each new version of the client-side component or each new version ofan associated configuration file.
 23. The method of claim 16, whereinthe client-side component is no larger than about 30 Kbytes.
 24. Themethod of claim 16, wherein the client-side component runs in an adplayer on the client device.
 25. The method of claim 16, wherein theclient device is a mobile phone.
 26. A computer program product forfacilitating playback and tracking a video advertisement in a real-timebidding (RTB) system, the computer program product embodied on anon-transitory storage medium at a client device of the RTB system, thecomputer program product comprising: program code for, in response to arequest for the video advertisement sent by the client device to the RTBsystem, receiving, at a client-side component residing at the clientdevice, a first set of information associated with the videoadvertisement; program code for parsing, at the client-side component,the received first set of information to obtain the video advertisementand building, at the client-side component, tracking pixelscorresponding to respective predefined events associated with the videoadvertisement, wherein the predefined events include at least one of amidpoint playback of the video advertisement, a complete playback of thevideo advertisement, a pause in playback of the video advertisement, ora user interaction associated with the video advertisement; program codefor providing the video advertisement from the client-side component toa video player on the client device; program code for firing from theclient-side component a first tracking pixel of the tracking pixels uponoccurrence of a first predefined event of the predefined eventsassociated with the video advertisement; and program code for providing,based on the occurrence of the first predefined event, a second set ofinformation from the client-side component to a third-party serviceprovider that populates advertisement campaign information at thethird-party service provider.
 27. The computer program product of claim26, wherein the client-side component runs in an ad player on the clientdevice.
 28. The computer program product of claim 26, wherein the clientdevice is a mobile phone.